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Open  System  Design  and  Evolutionary  Acquisition 
Application  To  The 

National  Missile  Defense  Family  of  Radars 

Orazio  A.  Di  Marca  (USAF/ESC),  Stephen  B.  Rejto  (MIT/LL),  LCDR  Thomas  Gomez  (BMDO) 


Abstract 

The  traditional  acquisition  process  is  complex  and 
lengthy.  The  process  does  not  allow  appropriate  user 
interaction/feedback  and  often,  due  to  its  extended 
period  of  performance,  continuity  in  program  office 
personnel  is  lost.  Developments  usually  experience 
schedule  slips  and  cost  over  runs. 

Traditional  acquisitions  usually  develop  closed  (stove 
piped)  systems  employing  “custom”  component  with 
“tightly  coupled”  software  and  hardware.  The 
developments  lack  open  system  architectures  and  have 
minimal  commonality,  standard  interfaces,  and 
protocols.  The  systems  when  fielded,  usually,  are 
outdated  and  become  obsolete.  They  are  difficult  to 
operate  and  frequently  are  surpassed  by  current 
technology.  They  do  not  easily  allow  state-of-the-art 
technology  insertion  and  use  of  the  latest  Commercial- 
Off-The-Shelf  (COTS)  equipment.  Progressively,  they 
become  more  expensive  to  maintain. 

Acquisition  reforms  have  introduced  new  innovative 
approaches  to  systems  procurements.  Open  System  (OS) 
design  methodology  and  the  Evolutionary  Acquisition 
(EA)  implementation  of  the  spiral  process  offer  a 
framework  for  achieving  a  shorter  acquisition  timeline, 
ability  to  leverage  COTS,  improve  weapon  systems 
performance,  allow  technology  “refresh”,  and  lowers  the 
overall  life  cycle  costs. 

Federally  Funded  Research  &  Development  Centers 
(FFRDCs)  have  used  an  open  system  approach  in  their 
radar  developments.  Transitioning  their  technology 
design  methodology  to  industry  will  reduce  acquisition 
and  life  cycle  costs.  More  importantly,  it  would  allow 
leveraging  of  industry’s  rapid  advances  in  commercial 
technological  development.  It  will  also  facilitate  system 
upgrades  to  keep  up  with  the  evolving  threats. 


acquisition  reforms  to  improve  and  shorten  the 
development  timelines.  Figure  1  illustrates  the  history 
of  sophisticated  high  power  radar  developments  since 
the  late  sixties.  The  figure  depicts  frequency  of 
operation  and  the  approximate  timeframe  the  radars 
were  developed  by  both  FFRDCs  and  industry.  It  also 
groups  radar  systems  that  are  related  in  their  system 
functions.  A  close  inspection  of  the  figure  shows  that 
radars  are  grouped  in  a  specific  “family”  of  radars  that 
operate  both  at  narrow  and  wide  bandwidths.  Note  that 
the  X-Band  family  of  radars  is  not  isolated  only  to  the 
GBR  system  and  its  previous  prototype  developments, 
rather  the  family  of  radars  include  systems  with 
wideband  and  imaging  capability:  the  Haystack  radar, 
HAX,  MMW,  COBRA  DANE,  COBRA  JUDY  S-Band, 
COBRA  JUDY  X-Band,  HAVE  STARE,  THAAD, 
COBRA  GEMINI,  and  the  recent  prototype  Ground 
Based  Radar  (GBR-P)  situated  at  the  Kwajalein  missile 
range.  Furthermore,  the  figure  also  illustrates  the 
limited  transfer  of  technology  from  one  development  to 
another,  and  potential  capability  for  future  transfer  of 
technology  from  one  system  to  another  as  improvements 
and  technology  advances  are  made. 


. 


i  m  is* 


Introduction 

Due  to  a  variety  of  reasons,  defense  firms  have  lagged 
behind  in  leveraging  FFRDC’s  technological 
innovations  and  Department  of  Defense  (DoD) 


Figure  1.  High  Power  Radars 

A  number  of  efforts  have  addressed  means  of 
overcoming  the  high  cost  drivers  in  the  design  and 
development  and  modification  of  these  highly  complex, 
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high  power  surveillance,  threat  warning,  tactical  and 
range  instrumentation  radar  systems.  These  drivers 
include,  but  are  not  limited  to,  complexity  of  radar 
designs;  stove-pipe  designs;  lack  of  competition;  use  of 
different  programming  languages;  non-standardization 
of  hardware  components;  interface  incompatibilities; 
quality  of  workmanship;  pushing  the  “state-of-the-art”; 
design  changes;  multi-mission  capabilities;  operation  in 
harsh  climates;  etc.  Figure  2  illustrates  the  similar 
functions  yet  some  incompatibility  of  both  hardware  and 
software  of  several  representative  current  radar  system 
designs. 


(Ui  - 

:SSM- 

g 

gi 

; 

£  "V 

ftfatfiim.- 

ftratbj ** 

_ i 

cpBpait) 

TJLyia 

MM 

. 

1.1. . 

V-rtrAtv* 

MM1?. 

m  m 

M 

Mi 

li 

GRPOfFR] 

■.  IKflX*> 

FIGURE  2  -  Notional  Radar  Incompatible 
Subsystems  performing  similar  functions 

Although  the  representative  radar  subsystems  perform 
the  same  functionality,  different  components  are  used 
with  minimal  regard  to  interfaces,  commonality  and 
standardization. 


Limitation  of  NMD  Existing  Radar  Designs 

Current  NMD  radar  designs  and  other  defense 
establishment  developed  systems  do  not  have  an  open 
architecture  as  defined  by  the  Office  of  the  Secretary  of 
Defense,  Joint  Task  Force  on  Open  Systems.  Designs 
lack  standardization  and  commonality  between  radar 
systems,  lack  standard  interfaces,  incorporate  minimal 
amount  of  COTS  and  maximize  use  of  “custom” 
components.  Both  hardware  and  software  are  “tightly” 
coupled  making  future  modifications/upgrade  complex, 
lengthy,  and  costly.  As  a  result,  upgrades  can  only  be 
done,  successfully,  by  the  original  developer. 


Open  Systems  (OS) 

OS  design  decomposes  a  system  in  a  distributed, 
loosely  coupled,  subsystem  “open”  architecture, 
characterizing  and  defining  all  subsystems, 
interfaces,  and  protocols.  In  today’s  environment 
of  rapid  advances  in  technology,  signal  processing, 
and  manufacturing,  open  systems  design  is  the  best 
design  solution  in  reducing  life  cycle  costs.  The 
OSD  Open  System  Joint  Task  Force  has  a  web  page, 
http:/www.acq.osd.mil/osjtf,  that  offers  a  tutorial  in 
the  Open  System  design  approach.  Figure  3  depicts 
the  historical  DoD  development  cycle  taking  8-15 
years  to  design,  develop  and  deploy  a  major  system 
as  compared  to  the  commercial  market  that 
develops  new  technology  4  to  8  times  faster.  Due  to 
commercial  market  dynamics,  supporting 
technology  is  constantly  evolving  at  approximately 
18  month  cycles.  An  open  system  architecture 
allows  this  new  technology  to  be  inserted  with 
minimal  impact  to  the  system’s  operation. 


SYSTEM  DEVELOPMENT  CYCLES 
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FIGURE  3  —  System  Development  Cycles 


Figure  4  depicts  the  open  system  design 
methodology.  Open  Systems  facilitates  using  up-to- 
date  technology  in  DoD  Weapon  Systems,  even  if  the 
supporting  technology  changes  at  a  rapid  rate.  An  open 
system  is  a  collection  of  interacting  components 
designed  to  satisfy  stated  needs.  All  components 
conform  to  formal  interface  specifications.  Interactions 
among  the  components  depend  on  the  interface 
specifications;  in  particular,  the  interface  specification 
of  all  components  in  an  open  system  is 


•  Fully  defined, 

•  Available  to  the  public,  and 

•  Maintained  according  to  group  consensus. 
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An  open  system  approach 


•  Is  an  integrated  technical  and  business  strategy. 

•  Uses  modular  hardware  and  software  design. 

•  Buys,  rather  than  builds,  individual  components. 


A  key  aspect  of  OS  is  a  focus  on  decomposition  and 
interfaces,  which  provides  maximum  flexibility  in 
developing  and  maintaining  a  system.  By  decomposing 
a  system  into  functional  units  that  are  connected  using 
open  interfaces,  developers  can  select  components  from 
a  competitive  marketplace  based  on  performance, 
quality,  and  price.  Replacing  older  parts  with  new 
components  that  adhere  to  the  standard  interface 
provides  a  maintenance  and  upgrade  solution  that 
minimally  impacts  the  rest  of  the  system. 


Open  System  Definitions 
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FIGURE  4  -  Open  Systems  Design  Methodology 

A  common  example  of  an  open  system  is  the  personal 
computer,  which  provides  standard  interfaces  for  disk 
drives,  graphic  cards,  and  other  peripherals.  By 
focusing  on  the  interfaces,  personal  computers  can  be 
built  using  the  best  new  low-cost  technology.  Customers 
also  benefit  by  being  able  to  replace  or  upgrade 
components  independent  of  a  specific  vendor. 


thereby,  allowing  continuous  upgrading/modemizing 
using  the  latest  COTS  components,  at  minimal  cost  to 
its  sponsors.  The  radars  continuously  get  upgraded  with 
the  latest  state-of-art  technology.  Systems  are 
“refreshed”  with  COTS  as  advances  in  the  commercial 
sector  occur.  By  using  an  open  design,  leveraging 
COTS,  and  inserting  new  technology  at  the  appropriate 
times,  the  radars,  essentially,  never  become  obsolete. 
Figure  5  and  Figure  6  depict  the  ROSA  design 
methodology. 


FIGURE  5  -  Historical  “Stovepipe”  Design  vs.  ROSA 


FIGURE  6  -  ROSA  System 


The  following  design  &  development  activities  by  the 
Laboratory  in  partnership  with  Government  services 
demonstrate  the  feasibility  of  the  ROSA  design 
methodology: 


FFRDC  Investments  in  Open  System  (OS) 
Developments 

The  MIT’s  Lincoln  Laboratory  (MIT/LL)  has  used  open 
system  design  methodology  in  their  state-of-the-art  radar 
technology  developments.  This  methodology  has 
become  known  as  the  Radar  Open  Systems  Architecture 
(ROSA).  Ever  since  the  development  of  the  high  power 
Haystack  radar,  the  Laboratory  has  minimized  “custom” 
components  and  maintained  “open”  radar  designs, 


Processing  And  Control  System  (PACS)  Distributed 
Systems  Implementation  at  Kwajelein 
•  The  PACS  system  implemented  a  distributed 
(open)  processing  architecture  that  was  utilized  at 
the  Kwajalein  Discrimination  System. 

Haystack  (X-Band)/Haystack  (Ku-Band)  Auxiliary 
Radar  (HAX)  (PACS  upgrades) 

•  The  distributed  architecture,  the  PACS, 
was  transitioned  to  the  Haystack  radar  and 
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its  design  methodology  used  in  the 
development  of  the  HAX  radar. 

COBRA  GEMINI  (S/X  Bands)  Development 
•  Prototype  development  of  a  high  power, 
dual  band,  mobile  radar,  within  24  months, 
“ESC/MITRE/LL”  team  using  a  Radar 
Open  System  Architecture  and  maximum 
use  of  emerging  technology  and  COTS 
components.  Figure  7  depicts  the  COBRA 
Gemini  development  during  testing  at 
MIT/LL’s  Millstone  Hill  and  sea-based 
application. 


FIGURE  7  -  COBRA  GEMINI  Prototype  Dual  Band 
Radar  System 

Kwajelein  Modernization  and  Remoting  Facility 
Upgrades 

•  Program  funded  by  the  Army  to  upgrade, 
insert  new  COTS  technology,  standardize 
and  establish  commonality  for  multiple 
radar  facilities  (ALCOR  (C-Band), 

TRADEX  (L/X-Bands),  MMW  (KAAV- 
Bands),  ALTAIR  (V/U-Bands))  using 
ROSA.  Figure  8  depicts  subsystems 
components  utilizing  COTS. 


FIGURE  8  -  KMR  ALCOR  subsystem  Components 


Haystack  (X)/HAX  (Ku)/Millstone  (L)  Upgrades 
•  AFSPC  funded  effort  to  upgrade,  insert 
emerging  COTS  technology  and  establish 
commonality  for  the  Haystack,  the  HAX, 
and  Millstone  radar  facilities  using  ROSA. 

The  OS  architecture,  available  subsystems, 
and  generic  radar  software  have  drastically 
reduced  the  cost  for  the  modernization 
effort  at  Millstone  Hill. 

The  above  examples  of  the  Radar  Open  System 
Architecture  design  methodology  can  and  should  be 
exploited  in  existing  and  new  NMD  designs. 
Transferring  this  design  methodology  to  BMDO’s  NMD 
developments  will  assist  NMD  developers  to  migrate  to 
an  open  system  radar  architecture. 

Acquisition  Reforms  and  the 
Evolutionary  Acquisition  (EA)  Process 

Many  studies  of  past  historical  acquisitions  and  revised 
NMD  cost  estimates  have  shown  that  DoD  weapon 
systems’  cost  continue  to  increase.  The  Evolutionary 
Acquisition  (EA)  process  was  implemented  to  attempt  to 
reduce  the  acquisition  costs  and  timelines  for  fielding  a 
product. 

EA  is  a  nontraditional,  overarching  acquisition  strategy 
whereby  a  core  capability  meeting  a  valid  requirement  is 
fielded  with  the  intent  to  develop  and  field  successive 
additional  capabilities  in  spirals,  as  requirements  are 
further  defined,  throughout  the  mission  operational  life 
of  the  system.  EA  offers  a  more  rapid  fielding  of  a 
solution  to  a  customer’s  requirement  even  if  only  a 
partial  solution.  It  also  offers  continuous  improvement 
of  the  product  and  concept  of  operations  toward  a  100% 
solution  through  subsequent  spiral  cycles.  Figure  9 
illustrates  the  Spiral  Process  originally  implemented  at 
the  Air  Force’s  Electronic  Systems  Center  (ESC)  under 
the  leadership  of  LTG  Kadish. 

Spiral  Development 


FIGURE  9  -  Spiral  Development  Process 
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Spiral  Development  Application  at  ESC 

The  Spiral  Development  process  and  use  of  the 
Command  &  Control  (C2)  Unified  Battlespace 
Environment  (CUBE)  at  ESC  for  integrated  testing  and 
verification  guided  the  SPOs  in  leading  Integrated 
Product  Teams  (IPTs)  to  deliver  the  required  C2 
capability  within  the  specified  cost,  schedule,  and 
performance  parameters  in  accordance  with  the 
standards  defined  by  the  Defense  Information 
Infrastructure  -  Common  Operating  Environment  (DII- 
COE)  and  the  Joint  Technical  Architecture  (JTA).  The 
framework  also  provided  the  means  for  the  SPOs  to 
provide  feedback  for  changes  to  the  DII-COE  and 
additional  capabilities  requirements  for  inclusion  in 
future  upgrades. 

Command  &  Control  acquisitions  are  ideal  candidates 
for  the  EA  process  because  the  system  requirements  are 
difficult  to  quantify  and  they  are  expected  to  change  as  a 
function  of  scenario,  mission,  theater,  and  emerging 
technology.  Spiral  Development  allows  the  necessary 
rapid  system  upgrades  keeping  in  step  with  the  evolving 
threat  and  emerging  technology.  Figure  10  illustrates  a 
notional  application  of  the  Spiral  process  to  the  BMDO 
NMD  architectures. 


Spiral  Development  Application  to 
DMI)  Radars 
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pursued.  Without  an  open  system  architecture, 
technology  that  is  currently  being  developed  cannot 
easily  be  transitioned  at  the  appropriate  development 
completion  dates. 


Defense  Information  Infrastructure 
Common  Operating  Environment  (DII 
COE) 

The  Defense  Information  Systems  Agency  (DISA)  is  the 
caretaker  of  the  DII  COE.  The  DII  COE  is  Mission 
Application  Independent.  It  is:  an  architecture;  an 
approach;  a  collection  of  reusable  software;  a  software 
infrastructure;  a  set  of  guidelines  and  standards.  The 
software  is  developed  in  layers:  the  kernel;  infrastructure 
services  (data  exchange)  and  common  support 
applications.  The  mission  applications  work  on  top  of 
the  kernel,  infrastructure  services  and  common  support 
applications. 


Benefits  to  BMD  Radars 

Implementing  the  above  design  approaches  offer  open 
systems,  commonality,  interoperability,  portability, 
supportability  and  affordability.  These  approaches 
refrain  from  using  custom  developments,  proprietary 
hardware  and  software.  The  radar  functionality  is 
decomposed  into  building  blocks  using  industry 
standard  open  system,  commercial  products  and 
standard  interfaces  making  future  upgrades  less  complex 
and  cost  effective.  Benefits  can  be  summarized  as 
follows: 

•Reduced  Total  Cost  of  Ownership 

-  “Design-specific”  independence  enables  future 
support  and  rapid  upgrades. 

-  Enables  flexibility  and  cost  advantages  of 
multiple  sources  of  supply. 


FIGURE  10  -  Notional  Spiral  application  to  BMDO’s 
NMD  Architectures 

The  Spiral  Process  goes  “hand-in-hand”  with  an  Open 
system  architecture.  Without  it,  “technology”  will  be 
developed  for  “technology”  sake  with  a  small  chance  of 
being  transitioned.  Due  to  the  large  investment  made 
in  the  present  NMD  designs,  it  becomes  cost  prohibitive 
to  “force”  an  open  system  architecture  on  the  existing 
NMD  developments.  However,  a  plan  to  migrate  to  an 
open  system  architecture  is  feasible  and  should  be 


•Decreased  development  costs  and  schedule  by 
leveraging  commercial  technology  R&D, 
competition,  test,  and  quality  control 

-  Best  lowest  cost  product  vs.  single  in  house  product 

-  Purchase  vs.  specification,  design,  review,  produce 

-  Warranty  vs.  test 

•Enables  spiral  development  process 

-  Can  deploy  latest  technology  available 

-  Ability  to  use  technology  insertion  to 
meet  evolving  threat 
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Radar  Open  System  Architecture  (ROSA) 
Application  to  NMD  Family  of  Radars 
(THAAD,  GBR,  UEWR) 

Migration  of  current/potential  NMD  radar  operational 
systems  and  designs  to  an  open  system  architecture  is 
feasible,  cost  effective,  and  can  be  performed  in  an 
evolutionary  (spiral)  fashion.  As  part  of  BMDO’s 
Advanced  Radar  Technology  program,  migration  of 
open  system  architecture  to  NMD  systems  is  being 
investigated.  The  migration  can  be  initiated  by  first, 
making  an  assessment  of  current  designs  by  applying 
FFRDC  developed  tools  (e.g.  MITRE  developed  Model 
Reference  Technology  (MRT))  to  decompose  and 
characterize  the  systems.  MRT  is  a  tools-supported 
modeling  and  simulation  technology  process  that 
enforces  the  disciplined  use  of  models  and  simulation  to 
solve  project,  management  and  system  engineering 
problems.  MRT  is  comprised  of  a  tailorable  process,  a 
system  engineering  approach,  and  a  federated  set  of 
tools. 

MRT  includes  reverse  engineering  capability  of  legacy 
code  and  provides  an  integrated,  system  and  technical 
view  compatible  with  Joint  C4ISR  Architecture 
Planning/Analysis  System  (JCAPS).  It  permits  drill 
down  from  requirements  “shalls”  to  lines  of  code 
associated  with  its  (“shall”)  implementation.  It  provides 
a  birds  eye  view  of  the  traffic  flow  (digital  bits)  within 
the  system  and  helps  to  identify/define  interfaces  and 
use  of  protocols.  It  also  assists  in  defining  those 
“custom”  areas  in  current  NMD  radar  design  that 
prevent  the  systems  from  being  open.  Once  the 
appropriate  identification  and  definition  of  all  interfaces 
and  protocols  are  made,  a  planning  schedule  can  be 
developed  to  illustrate  an  evolutionary  acquisition  using 
spirals  of  development  to  migrate  to  a  Radar  Open 
System  Architecture. 

Figure  11  depicts  the  MRT  process  as  applied  to  the 
COBRA  GEMINI  prototype  development  effort.  Legacy 
Systems  software  source  code  was  obtained  and  reverse 
engineered  to  identify  low  level  architectural  features. 
In  combination  with  other  MITRE  and  COTS  reverse 
engineering  tools,  a  design  package  was  developed  that 
served  as  a  basis  for  follow-on  software  fabrication, 
training,  and  software  maintenance. 


FIGURE  11  -  Model  Reference  System  Engineering 
Process 


For  BMDO  NMD  systems,  the  migration  to  a  radar  open 
system  architecture  can  easily  be  demonstrated,  cost 
effectively,  by  transitioning  the  FFRDC  ROSA  design 
methodology  to  the  Theater  High  Altitude  Area  Defense 
(THAAD)  User  Operational  Evaluation  System  (UOES) 
phased  array  radar.  As  reported  by  BMDO’s  POET 
future  Radar  Acquisition  Roadmap  Study  Team 
(RARST),  the  THAAD  UOES  are  becoming  costly  to 
maintain  and  unsupportable  due  to  a  variety  of  reasons. 
It  was  recommended  that  a  potential  solution  was  to 
migrate  the  radars  to  an  open  system  architecture  The 
same  programmatic  and  design  philosophy  used  in 
design  and  development  of  the  COBRA  GEMINI  and 
other  FFRDC  legacy  systems  would  be  applied  to  the 
prototype  design  and  development  of  THAAD  UOES 
replacement  subsystems.  At  completion  of  subsystem 
testing  and  integration  by  a  team  of  Government, 
FFRDCs  and  industry,  existing  THAAD  subsystems, 
with  the  exception  of  the  phased  array  antenna,  would 
be  replaced  with  the  newly  developed  ROSA  compliant 
COTS  equipment.  Figure  12  illustrates  a  notional  three 
phased  approach  in  pursuing  this  course  of  action., 
RQSA  application  to  THAAD  Radar 
_ CRATHR) _ 
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FIGURE  12  -  Three  Phase  Approach  to  THAAD 
ROSA  Migration 
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ROSA  Potential  Migration  to  Other  Radar 
Developments  (Ground-based,  Sea-based, 
Airborne)  and  BMC3  NMD  Architecture 

Classes  of  radars  consist  of  more  than  just  the  “Family 
of  GBR  radars”,  a  term  that  we  have  heard  so  often.  The 
radar  field  includes  not  only  the  “GBR”  kind  of  systems, 
but  it  also  includes  airborne,  surface  based  (land  or  sea) 
and  space  based.  Implementation  of  open  system  design 
applies  not  only  to  the  “GBR”,  but  also  to  any  other 
radar  system  design. 

Since  C2  acquisitions  are  ideal  candidates  for  the  EA 
process  due  to  changing  requirements  as  a  function  of 
scenario,  mission,  theater,  and  emerging  technology,  the 
BMC3  NMD  architecture  would  benefit  from  an  OS  and 
an  Evolutionary  Acquisition  approach. 


Summary/Conclusion 

The  key  to  achieving  competition,  commonality,  ease  of 
COTS  refresh,  assure  interoperability,  lower  O&M 
costs,  software  portability,  lower  life  cycle  costs,  etc.,  is 
to  implement  Joint  Technical  Architecture  (JTA)  and 
Defense  Information  Infrastructure  Common  Operating 
Environment  (DII  COE),  open  system  design,  and 
standard  interfaces  and  protocols.  Where  standards 
(both  Government  and  Industry)  do  not  exist,  they  need 
to  be  established.  Open  Systems  provides  a  cost- 
efficient  means  to  deploy  new  technology  in  existing 
sensors  and  new  system  developments.  Open  System 
design  approach  is  “essential”  and  has  to  be  made 
mandatory  in  any  DoD  system  acquisition.  The 
Standards  Committee  of  the  Institute  of  Electrical  and 


Electronic  Engineers  (IEEE)  and  the  OSD  JTF  on  Open 
Systems,  together  with  the  support  of  industry,  are  the 
offices  that  could  perform  a  detailed  investigation  and 
assessment,  and  ultimately,  establish  interface 
“standards”  for  the  development  of  radar  systems. 
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Attached  is  the  final  version  of  Paper  #9-7,  Open  System  Design  and  Evolutionary  Acquisition  Application 
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